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Description 

In complex electronic control systems, the con- 
trol must respond to various occurrences such as 
input conditions (a change of state of a switch), 
lapsed time periods, or completion of specific 
tasks. This is often referred to as event detection 
and discrimination, and sometimes the events are 
common and sometimes of a rare or unique 
nature. Frequently, the next control sequence is a 
control procedure responsive to more than one 
event or condition, it is often necessary for the 
control to wait for the occurrence of each event 
upon which the next action was dependent. 

It is known in the prior art to be able to suspend 
the control to wait either on time or an input 
change to continue operation. In some situations, 
the control is waiting for a plurality of events or 
conditions but it is only necessary for the occurr- 
ence of one of the events or conditions to trigger 
the appropriate response. Watting for 
unnecessary conditions can be wasteful of control 
time. On the other hand, the timing of conditions 
or suspensions in a control is often an important 
failsafe technique. 

It would be desirable, therefore, to provide a 
control mechanism which is responsive to arrival 
of any one of a plurality of conditions or events 
through a series of steps specific to the particular 
input It would also be desirable to provide a 
control that can execute on a plurality of events 
but actually executes upon sensing the first 
occurrence of an event, ignoring the later events. 

Accordingly the present invention overcomes 
these problems by providing a system and a 
method for controlling a machine-as claimed in 
the appended claims 1 and 5. 

Further advantages of the present invention will 
become apparent as the following description 
proceeds, and further features characterizing 
embodiments of invention will be pointed out 
with particularity in the subordinate claims. 

With a solution according to the present inven- 
tion, it is possible to race two or more conditions 
against each other to trigger a control response. 
In particular, a portion of the machine control is 
suspended such as an input, a time delay, avail- 
ability of data, or completion of a task. These 
conditions race against one another. That is, the 
occurrence of one of the conditions will initiate 
the response, and ail other conditions will then be 
ignored. The type of response depends upon the 
particular condition that occurred first. 

For a better understanding of the present inven- 
tion reference may be had to the accompanying 
drawings wherein the same reference numerals 
have been applied to like parts and wherein: 

Figure 1 is an elevational view of a reproduction 
machine typical of the type of machine or process 
that can be controlled in accordance with the 
present invention; 

Figure 2 is a block diagram of a first level of 
control architecture for controlling the machine of 
Figure 1; 

Figure 3 illustrates a second level of control 


architecture, in particular a virtual machine In 
accordance with the present invention, for con- 
trolling the machine of Figure 1; 

Figure 4 is an illustration of the relationship of 
5 the first level and second level of controls of the 
controls shown in Figure 1; 

Figures 5a and 5b illustrate a RAM map in 
accordance with the present invention; 

Figure 6 illustrates one aspect of the operation 
w of the Task Manager according to the present 
invention; and 

Figure 7 illustrates one aspect of the Scheduler 
Manager control in accordance with the present 
invention. 

16 With reference to Figure 1, there is shown an 
electrophotographic printing or reproduction 
machine employing a belt 10 having a photocon- 
ductive surface. Belt 10 moves in the direction of 
arrow 12 to advance successive portions of the 

20 photoconductive surface through various pro- 
cessing stations, starting with a charging station 
including a corona generating device 14. The 
corona generating device charges the photocon- 
ductive surface to a relatively high substantially 

25 uniform potential. 

The charged portion of the photoconductive 
surface is then advanced through an imaging 
station. At the imaging station, a document 
handling unit 15 positions an original document 

30 16 facedown over exposure system 17. The 
exposure system 17 includes lamp 20 illuminating 
the document 16 positioned on transparent platen 
18. The light rays reflected from document 16 are 
transmitted through lens 22. Lens 22 focuses the 

35 light image of original document 16 onto the 
charged portion of the photoconductive surface 
of belt 10 to selectively dissipate the charge. This 
records an electrostatic latent image on the 
photoconductive surface corresponding to the 

40 informational areas contained within the original 
document 

Platen 18 is mounted movably and arranged to 
move in the direction of arrows 24 to adjust the 
magnification of the original document being 

45 reproduced. Lens 22 moves in synchronism there- 
with so as to focus the light image of original 
document 16 onto the changed portion of the 
photoconductive surface of belt 10. 
Document handling unit 15 sequentially feeds 

so documents from a holding tray, in seriatim, to 
platen 18. The document handling unit recir- 
culates documents back to the stack supported on 
the tray. Thereafter, belt 10 advances the electro- 
static latent image recorded on the photoconduc- 

ss tive surface to a development station. 

At the development station a pair of magnetic 
brush developer rollers 26 and 28 advance a 
developer material Into contact with the electro- 
static latent image. The latent image attracts toner 

60 particles from the carrier granules of the 
developer material to form a toner powder image 
on the photoconductive surface of belt 10. 

After the electronic latent image recorded on 
the photoconductive surface of belt 10 is 

65 developed, belt 10 advances the toner powder 
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image to the transfer station. At the transfer 
station a copy sheet is moved into contact with 
the toner powder image. The transfer station 
includes a corona generating device 30 which 
sprays ions onto the backside of the copy sheet. 
This attracts the toner powder image from the 
photoconductive surface of belt 10 to the sheet 
The copy sheets are fed from a selected one of 
trays 34 or 36 to the transfer station. After trans- 
fer, conveyor 32 advances the sheet to a fusing 
station. The fusing station includes a fuser 
assembly for permanently affixing the transferred 
powder image to the copy sheet Preferably, fuser 
assembly 40 includes a heated fuser roller 42 and 
backup roller 44 with the sheet passing between 
fuser roller 42 and backup roller 44 with the 
powder image contacting fuser roller 42. 

After fusing, conveyor 46 transports the sheets 
to gate 48 which functions as an inverter selector. 
Depending upon the position of gate 48, the copy 
sheets will either be deflected into a sheet inverter 
50 or bypass sheet inverter 50 and be fed directly 
onto a second gate 52. Decision gate 52 deflects 
the sheet directly into an output tray 54 or deflects 
the sheet into a transport path which carries them 
on without inversion to a third gate 56. Gate 56 
either passes the sheets directly on without inver- 
sion into the output path of the copier, or deflects 
the sheets into a duplex inverter roll transport 58. 
Inverting transport 58 inverts and stacks the 
sheets to be duplexed in a duplex tray 60. Duplex 
tray 60 provides intermediate or buffer storage for 
those sheets which have been printed on one side 
for printing on the opposite side. 

In order to complete duplex copying, the pre- 
viously simplexed sheets in tray 60 are fed 
seriatim by bottom feeder 62 back to the transfer 
station for transfer of the toner powder image to 
the opposed side of the sheet. Conveyors 64 and 
66 advance the sheet along a path which pro- 
duces a sheet inversion. The duplex sheets are 
then fed through the same path as the previously 
simplexed sheets to be stacked in tray 54 for 
subsequent removal by the printing machine 
operator. 

Invariably after the copy sheet is separated 
from the photoconductive surface of belt 10, 
some residual particles remain adhering to belt 
10. These residual particles are removed from the 
photoconductive surface thereof at a cleaning 
station. The cleaning station includes a rotatably 
mounted fibrous brush 68 in contact with the 
photoconductive surface of belt 10. 

A controller 38 and control panel 86 are also 
illustrated in Figure 1. The controller 38, as repre- 
sented by dotted lines, is electrically connected to 
the various components of the printing machine. 

With reference to Figure 2, there is shown a first 
level of control architecture of controller 38 illus- 
trated in Figure 1. In accordance with the present 
invention, in particular, there is shown a Central 
Processing Master (CPM) control board 70 for 
communicating information to and from all the 
other control boards, in particular the Paper 
Handling Remote (PHR) control board 72 control- 


ling the operation of all the paper handling sub- 
systems such as paper feed, registration and 
output transports. 
Other control boards are the Xerographic 
6 Remote (XER) control board 74 for monitoring 
and controlling the xerographic process, in par- 
ticular the digital signals; the Marking and Imag- 
ing Remote (MIR) control board 76 for controlling 
the operation of the optics and xerographic sub- 
io systems, in particular the analog signals. A Dis- 
play Control Remote (DCR) control board 78 is 
also connected to the CPM control board 70 
providing operation and diagnostic information 
on both an alphanumeric and liquid crystal dis- 
is play. Interconnecting the control boards is a 
shared communication line .80, preferably a 
shielded coaxial cable or twisted pair similar to 
that used in a Xerox Ethernet® Communication 
System. For a more detailed explanation of an 
20 Ethernet* Communication System, reference is 
made to pending applications D/78108, U.S. Serial 
No. 205,809; D/78108Q2, U.S. Serial No. 205,822 
and Dtf8108Q3, U.S. Serial No. 205,821, ail filed 
November 10, 1980 and incorporated herein as 
25 references. 

Other control boards can be interconnected to 
the shared communication line 80 as required. 
For example, a Recirculating Document Handling 
Remote (RDHR) control board 82 (shown in phan- 
30 torn) can be provided to control the operation of a 
recirculating document handler. There can also 
be provided a not shown Semi-Auto matic Docu- 
. ment Handler Remote (SADHR) control board to 
control the operation of a semi-automatic docu- 
35 ment handler, a not shown Sorter Output Remote 
(SOR) control board to control the operation of a 
sorter, and a not shown finisher output remote 
(FOR) control board to control the operation of a 
stacker and stitcher. 
40 Each of the controller boards preferably 
includes an Intel 8085 microprocessor with suit- 
able RAM and ROM memories. Also inter- 
connected to the CPM control board is a Master 
Memory Board (MMB) 84 with suitable ROMs to 
45 control normal machine operation and a control 
panel board 86 for entering job selections and 
diagnostic programs. Also contained in the CPM 
board 70 is suitable nonvolatile memory. All of 
the control boards other than the CPM control 
so board are generally referred to as remote control 
boards. 

In a preferred embodiment, the control panel 
board 86 is directly connected to the CPM control 
board 70 over a 70 line wire and the memory 

55 board 84 is connected to the CPM control board 
70 over a 36 line wire. Preferably, the Master 
• Memory Board 84 contains 56K byte memory and 
the CPM control board 70 includes 2K ROM, 6K 
RAM, and a 512 byte nonvolatile memory. The 

so PHR control board 72 includes 1K RAM and 4K 
ROM and preferably handles 29 inputs and 28 
outputs. The XER control board 74 handles 24 
analog inputs and provides 12 analog output 
signals and 5 digital output signals and includes 

65 4K ROM and 1K RAM. The MIR board 76 handles 
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13 inputs and 17 outputs and has 4K ROM and IK 
RAM. 

As illustrated, the PHR, XER and MIR boards 
receive various switch and sensor information 
from the printing machine and provide various 
drive and activation signals, such as to dutches 
and lamps in the operation of the printing 
machine. It should be understood that the control 
of various types of machines and processes are 
contemplated within the scope of this invention. 

In accordance with the present invention, with 
reference to Figure 3, there is shown a second 
level of control architecture, an Operating System 
(O.S.). The Operating System is shown by the 
dotted line blocks indicated by the numerals 96a, 
96b and 96c. The Operating System is shown in 
communication with the macros and assembly 
language instructions of a pair of micro- 
processors 98a and 98b. The Operating System 
could communicate with any number of micro- 
processors, for example, the microprocessors of 
each of the control boards 70, 72, 74, 76, 78 and 82 
shown in Figure 2. The Operating System overlies 
the control architecture of Figure 2 and, in 
general, acts as a manager of the various resour- 
ces such as the CPM and remote board micro- 
processors and the ROM and RAM memories of 
each of the control boards. In accordance with the 
present invention, the Operating System converts 
the raw microprocessor hardware into a virtual 
machine in controlling the printing machine 
shown in Figure 1. By virtual machine is meant 
that portion of the control illustrated by numerals 
96a, 96b and 96c that surround the system hard- 
ware. In effect, the Operating System presents a 
control more, powerful then the underlying hard- 
ware itself. 

With reference to Figure 3, the Operating 
System is presented with a plurality of Directives 
98. These Directives call upon one or more 
decoders or Instruction Modules 100. In turn, the 
Instruction Modules 100 invoke one or more 
Primitives. In particular, the Primitives are a 
Scheduler Manager 102, a Task Manager 104, a 
Data Base Manager 106, a Timer Manager 108 
and a Communication Manager 110. In turn, the 
Primitives communicate with the various micro- 
processors 98a, 98b through the macros 1 14, the 
assembly language 116 and the microcode 118 of 
the microprocessors 98a, 98b. The invoking of 
Instruction Modules and Primitives is illustrated 
in Figure 3 by the solid lines connecting the 
Directives (98), Instruction Modules (100) and 
Primitives (102, 104, 106, 108, 110). It should be 
noted that each of the microprocessors 112 is 
suitably connected to suitable RAM and ROM 
memories as well as with other microprocessors. 

Directives corresponding to macros in a physi- 
cal machine (microprocessor) architecture are the 
top level of the operating control. The Directives 
shield the Operating System structure from 
changes in the compiler, allow for changes in the 
Operating System internal structure and abstract 
out from the compiler unnecessary Operating 
System details, instruction Modules and 


Primitives make up the Operating System, 
instruction Modules are the middle level and 
correspond to assembly language instructions in 
a physical machine. They are the smallest execut- 

s able, nonpreemptive unit in the virtual machine. 
Preemption is similar to a physical machine 
interrupt capability except that a physical 
machine allows basically two concurrent pro- 
cesses or tasks (foreground or background) 

10 whereas the virtual machine allows an almost 
unlimited number of tasks executing in one or 
more physical processors. 

The Primitives are the lowest level in the Oper- 
ating System. They correspond to the microcode 

15 of a microprocessor. It is the function of the 
Primitives to implement the basic building blocks 
of the Operating System on a microprocessor and 
absorb any changes to the microprocessor, in 
general, Directives call upon one or more Instruc- 

20 tion Modules which in turn invoke one or more of 
the Primitives to execute a task or process. 

Preferably, the Instruction Modules 100 and the 
Primitives 102, 104, 106, 108 and 110 comprise 
software in silicon. However, it should be under- 

25 stood that it is within the scope of the present 
invention to implement the Instruction Modules 
and Primitives in hardware. They are building 
blocks in an overall control system. In particular, 
the Instruction Modules and Primitives generally 

30 provide a set of real time, multitasking functions 
that can be used generically across different 
implementations of the microprocessors. In a 
machine or process control, the Instruction 
Modules and Primitives are extensions of the 

35 instruction set of the microprocessor. The micro- 
processor with its original set of instruction 
Modules acts as a kernal, and the software and 
silicon or firmware acts as a shell. 
The machine control can be viewed as a nesting 

40 or overlay of successively higher levels of control 
as shown in Figure 4. At the lowest level, is the 
microprocessor or controller responding to the 
microcode, assembly language and macros. 
Overlying this physical machine is the virtual 

45 machine comprising the Primitives and Instruc- 
tion Modules responding to Directives. In effect, 
the Primitives break down the high level Direc- 
tives and Instruction Modules into a level for the 
microprocessor to perform. 

so An Instruction Module 100 in the operating 
system is known as a slice and one Instruction 
Module is given 500 microseconds to execute. 
The Instruction Modules are the smallest execut- 
able nonpreemptive units in the virtual machine. 

ss A listing and explanation of some of the more 
commonly used Instruction Modules 100 are 
given in Appendix A. 

Preemption is similar to the microprocessor 
interrupt capability except that a microprocessor 

€0 allows basically two concurrent processes (fore- 
ground and background). On the other hand, the 
virtual machine or Operating System allows an 
almost unlimited number of executions of concur- 
rent processes or tasks in one or more of the 

65 microprocessors. 
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That is, the Operating System can begin execut- 
ing several tasks in sequence by using the START 
instruction. Once each task is activated, it must 
wait its turn to have its next instruction executed. 
However, many tasks are active at the same time 5 
and being executed concurrently. 

By a process or task is merely meant any block 
of code that is executed by a microprocessor. 
These blocks of code provide computations, 
housekeeping or direct control of the process or w 
machine under control. 

The Primitives are the lowest level in the Oper- 
ating System. Primitives do not allow for implicit 
preemption and it is the function of the Primitives 
to implement the basic building blocks of the is 
Operating System on a physical machine (micro- 
processor) and absorb any changes to the physi- 
cal machine. Each of the Primitives is further 
broken down into sublevels known as primitive 
operations to carry out the operations of the zo 
particular manager. Appendix B lists various 
Primitive operations of the Scheduler Manager 
102 and Appendix C lists various Primitive oper- 
ations of the Task Manager 104. 

The portion of the Operating System residing in 25 
the CPM board 70 is known as the Dynamic 
Operating System (DOS). As an example of 
memory allocation, in the CPM board 70, there is 
preferably 6K bytes of RAM for tables, 8K bytes of 
ROM for the Operating System, and 48K bytes of 30 
ROM for the application programs. 

The Operating System sets up various RAM 
tables throughout the system. Portions of the 
RAM associated with each of the control boards 
are allocated space for various initializing and run 35 
time control information of the Operating System. 
Each of the Primitives is responsible for maintain- 
ing information in the RAM necessary to syn- 
chronize and coordinate the overall control of the 
machine or process. For example, the Scheduler 40 
Manager 102 sets up a table in RAM preferably on 
the CPM board 70 defining the sequence or 
schedule of the completing of tasks or processes. 
It determines the priority of execution of the 
various scheduled tasks. A task or process that 45 
has been suspended or is waiting is not 
scheduled. However, once the event occurs that 
the task is waiting for, the task is then scheduled 
for execution. 

The Task Control manager 104 is the Primitive so 
that keeps track of the status of a particular 
process or task. It determines how the various 
operations are to be performed. For example, a 
particular task may require several Instruction 
Modules invoking many different Primitive oper- ss 
ations. The Task Control Manager keeps a table in 
RAM on appropriate control boads of the status of 
each of the tasks. The Data Base Manager keeps 
track of the variables or constants or other infor- 
mation that are required to complete a task. This so 
data is stored in a portion of RAM called a stack 
associated with each of the tasks. 

Thus, for each task to be completed, the task 
itself must be scheduled by the Scheduler Man- 
ager 102, the status of the particular task is kept 6S 


track of by the Task Control Manager 104 and any 
data required to complete the task is provided by 
the Data Base Manager 106. The Timer Manager 
108 Primitive provides the necessary timing con- 
trol for each task and the Communications Man- 
ager 110 Primitive provides the communications 
between the various control boards, preferably 
over a shared line. 

As an example of how the Operating System 
operates, it is often required in the control of the 
printing machine to suspend or delay an oper- 
ation for a set period of time. If a delay of 200 
milliseconds is required, a Directive WAITR; 200 
is used. This Directive invokes the Instruction 
Module $WAIT In turn invoking the Primitive 
operations: 

START TIMER 

SUSPEND TASK 

EXECUTE NEXT TASK which provide a 200 
millisecond delay. 

That is, an operation application code (control 
code in ROM) calls in a Directive. The Directive 
invokes one or more Instruction Modules 100. For 
example, if the application code calls in a WAIT 
DIRECTIVE, the WAIT Instruction Module will be 
invoked. 

In turn, the WAIT Instruction Module will invoke 
the Timer Manager and Scheduler Manager 
which in turn provide the Primitive operation to 
complete the task. Once the WAIT Directive has 
been disseminated to the proper Primitives for 
execution, the Instruction Module can accept 
another Directive. 

Essential to the Operating System control is a 
set of processes or tasks that can be executed. 
The control of the printing machine is dependent 
upon the proper scheduling and timely execution 
of these tasks. The activation of lamps, clutches, 
motors and response to various sensors and 
conditions is accomplished through the comple- 
tion of the predetermined tasks. A given number 
of tasks are active at any one time and the 
Operating System concurrently executes these 
active tasks. Many tasks are related to other tasks. 
The Operating System supports full process con- 
trol by means of Instruction Modules that invoke a 
process or task and maintain a thread of control 
with that process or invoke a task and maintain no 
linkages. Therefore, various Instruction Modules 
or procedures are provided by the Operating 
System to maintain links between related tasks. 

Thus, a START instruction or procedure spawns 
a completely independent task while a FORK 
procedure spawns a related task termed a Child. 
This Child becomes a member of the invoking 
task's family, also known as the Parent. Whenever 
a task is invoked by another task through a CALL 
procedure, the CALUng task is suspended 
(though still active) and the CALLed task becomes 
an active Child of the CALLing task. More detailed 
description of various instruction Modules are 
provided in Appendix A. 

All possible tasks are predefined and listed in a 
Static Task Control Block (STCB). The Static Task 
Control Block is a portion of Random Access 
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Memory and Read Only Mmeory in all Operating 
System control boards. The random access por- 
tion of the Static Task Control Block in the 
Dynamic Operating System (on CPM board 70) is 
illustrated in Figure 5a. 

With reference to Figures 5a and 5b, there is 
shown portions of the Dynamic Operating System 
RAM map, i.e. the allocation of RAM locations on 
the CPM controller board 70. In general, each of 
the Managers or Primitives has associated RAM 
space which only that primitive is allowed to use. 
The first two blocks or column 0 and 1 are 
allocated to the Communication Manager 110, 
and the next two columns as well as portions of 
columns 5— 8D, E and F are allocated to the Data 
Base Manager (DBM) 106, in particular byte and 
word stacks, event data and suitable pointers. The 
remainder of columns D, E and F are allocated to 
the Scheduler Manager 102, in particular, the 
priority section and forward and backward links to 
other tasks. 

The Task Control Manager (TCM) 104 is allo- 
cated portions of columns 5 through C as well as 
column 4. Column 4 is a portion of the Static Task 
Control Block that identifies the TCB number or 
RTID of the currently active instance of a task or 
process. The remaining portions of the RAM 
space allocated to the Task Control Manager 
comprise locations known as the Task Control 
Blocks or Buffers (TCBs). The Task Control Blocks 
are the active tasks and include a Compile Time 
Identification (CTID), a next instance designation, 
a Parent Run Time Identification (RTID), a Join 
RTID, an activation address, a condition variable, 
and an interpreter address table. The remaining 
allocations are allocated to the Timer Manager 
108, in particular, Real Time Clock (RTC) and 
Machine Clock (MC) data. 

In the preferred embodiment, there are a total 
of 255 tasks available that are identified in the 
STCB. The Task Control Manager 104 also main- 
tains the list of the currently active tasks (TCBs). 
Preferably, there are a maximum of 96 tasks that 
can be active at one time. This list is constantly 
changing as new tasks are started or activated 
and current tasks are suspended or deleted. There 
is a Task Control Buffer (TCB) associated with 
each instance of an active task. 

For a particular task, the Static Task Control 
Block will point to a particular Task Control Buffer. 
The buffer will list the identification of the task 
and such information as the identification of a 
Parent or previous task that the current task is 
related to and any other information linking the 
current task to any other task. 

Since the Operating System resides in more 
than one control board, each of the control board 
operating systems maintain the status infor- 
mation for a task in Task Control Blocks. 

In operation, when a task is invoked, a TCB is 
allocated and all of the necessary process infor- 
mation is inserted. If a task is Invoked by a 
processor with no thread of control, the Operating 
System looks where the task resides. If the task 
resides in the processor invoking the task (i.e. 
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resides locally), the task is allocated a TCB and the 
task execution is started. If the task is external, 
that is in a processor different from the invoking 
processor, the Operating System sends the invo- 

5 cation request over the shared line or communi- 
cations channel 80 to the appropriate Operating 
System of the processor maintaining the task. 
That Operating System allocates the task, a TCB, 
and starts the task. 

to If the task is invoked with thread of control and 
the task resides locally, then the task is allocated a 
TCB and part of the information in the new TCB 
and the Parent task TCB becomes the other Task 
Control Buffer's IDs. If the new task is external, 

is then the task is allocated a TCB locally and the 
Parent and Child tasks are tagged with each 
others IDs and the Operating System sends the 
request to the appropriate Operating System in 
the network. The operating system then allocates 

20 a TCB for the Child task and a TCB for the Parent 
task and the appropriate tags are again made. 
This means that there is a pseudo TCB in each of 
the processors to represent the status of the 
Parent or Child task that resides in a different 

25 processor. 

• Certain task control Instruction Modules can 
modify that status. The current process control 
Instruction Module set Is START for task invoca- 
tion with its own, new, thread of control, FORK for 

30 task invocation with a thread of control, JOIN to 
allow a Parent task to synchronize with the Child, 
END to allow the Child task to join or synchronize 
to the Parent, and CANCEL to allow a Parent task 
to terminate the Child task. CANCEL is also used 

35 to terminate a STARTed task. All terminations 
cause the affected task to execute its WILL 

This system of using pseudo TCBs to represent 
a Parent or Child process in another processor 
gives the entire Operating System the capacity of 

40 making any task executable from any of the 
processors and thereby transparent to the 
applications software that generates the request 
As by way of example, allocation of TCBs and 
relationship with other TCBs reference is made to 

45 Figure 6. The left column CPM (1) illustrates the 
CPM board 70 identified as number 1 and the 
right column RDH (2) illustrates the RDH board 82 
identified as number 2. it is also assumed that 
there is a Task A, i.e. a block of code to be 

so executed, residing in the CPM ROM, and a Task B 
residing in the RDH ROM. A Compile Time ID 
(CTID) of 35 has been arbitrarily given Task A and 
a Compile Time ID of 55 has been given Task B. 
With reference to column 1, in the first row after 

55 CPM (1 ), there is shown Task A with a CTID of 35 
and no board identification meaning that the task 
resides on the CPM board. In the next row with a 
CTID of 55 is Task B. Task B has an identification 
of 0002 meaning that the Task B resides in ROM 

60 on the RDH board. 

Now assume that Task A has been invoked or 
called upon and is being executed. The code for 
Task A in RAM is illustrated by the block labelled 
A under Task A. At some point in Task A there will 

65 be a call to Task B residing in the RDH ROM. 
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With reference to column 1 under the RAM 
memory section, Task A is being executed 
because at some point in time Task A had been 
called upon in the control. At the time Task A was 
called upon, a Task Control Buffer was estab- 
lished in RAM memory on the CPM board, placing 
Task A in the system as an active task. The Task 
Control Buffer provides information concerning 
the specific task, in particular its relationship to 
other tasks. Since the RAM memory Task Control 
Buffers are allocated arbitrarily, Task A is shown 
as the second allocation in the RAM TCB on the 
CPM board. That is, it is given a Run Time 
Identification (RTIO) of 2, the Compile Time ID 
number 35 Is recorded. If Task A was related to 
another task, at this time a number would appear 
under the Parent ID (P-ID). At this point it is also 
not known if the Task A will be joined to any other 
task therefore the Join ID (J-ID) number is blank. 
The Task A resides in the CPM module therefore 
no address is given under the address block. 

Now assume the Task A has proceeded to the 
point of calling Task B. At this point, the identifica- 
tion ID 55 of Task B in the Static Task Control 
Block will be examined, and it will be determined 
that Task B resides on the RDH board. Task B will 
be allocated a buffer in the CPM RAM with a CUD 
of 55 as shown. It is arbitrarily given a RTID 
number 1 and identified in the Task Control Buffer 
with certain information. Since the Parent or 
calling task is Task A, the number 2 will be put in 
the P-ID column. Since there is no task to be 
joined known at this time, a 0 is put in the J-ID 
block and the address shows the address of the 
location of the task. 

The control then vectors to the execution of 
Task B in ROM in the RDH board. At this time, the 
RAM memory in the RDH control board is allo- 
cated a Task Control Block arbitrarily shown as 
Run Time ID number 4, and CTID 55. The Parent of 
Task B is Task A indicated by the number 3. Also, 
a block in the RDH RAM is allocated for Task A, ID 
35. Additional information for task 35 is included 
in this Task Control Block, in particular the Join ID 
number 4 and the address 0001. This information 
identifies the Task A as being related to Task B 
with the return to Task A after the completion of 
Task B. 

It should be noted that the Task Control Block in 
the RDH RAM memory for Task A is in essence a 
pseudo allocation since a block has already been 
allocated for Task A in the CPM RAM memory. 
Similarly, the allocation of a block in CPM RAM 
for Task B is merely a pseudo representation 
since Task B has already been allocated a Task 
Control Block in the RDH RAM. 

The Scheduler Manager 102 of the Operating 
System partitions segments of the micro- 
processors time among all active tasks. The 
Scheduler Manager is responsible for determin- 
ing which task is to receive the next chance to 
execute. 

The Scheduler Manager 102 consists of a 
medium term scheduler and a short term 
scheduler. The medium scheduler determines 


which tasks are to receive execution time and 
determines the priority of execution. The short 
term scheduler is responsible for determining 
which task executes next. 

5 The medium term scheduler handles the state 
transition of active tasks. The states of tasks are: 
(1) Queued. Those tasks desiring an execution 
slice. Each Operating System's Instruction Mod- 
ule takes exactly one slice. A slice is the time the 

10 current task was given a chance to execute until it 
completes its first Operating System Instruction, 
approximately 500 microseconds. In order to 
achieve this, most of the Operating System 
Instructions execute the short term scheduler 

is primitive upon completion of an Instruction. 
Other Instructions use the medium term 
scheduler primitive to change the attributes of 
tasks, (see Appendix B for more details on the 
Scheduler Manager Primitives). 

20 (2) Suspended State. That is, the task is not to 
be considered for execution at the present time 
but will eventually want to execute, and 

(3) Dead state. That is, the task is not known to 
the scheduler and therefore cannot receive an 

25 execution slice. 

Each task that is scheduled has an associated 
priority. This determines how often a task is given 
the chance to execute with respect to all other 
tasks. Queued and suspended tasks both have 

30 priorities. Suspended tasks are associated with a 
priority so that the medium term scheduler can be 
used to queue them at the priority they are 
suspended at. The short term scheduler is 
unaffected by the dead and suspended tasks. 

35 The Scheduler decides which of the queued 
tasks to execute by viewing the data structures 
associated with each task, that is, a priority and 
two links. These are found in the CPM RAM as 
illustrated in Figure 5b. The two links are arranged 

40 to form a doubly linked circular list of tasks. The 
Scheduler generally decides that the next task to 
execute is the task that the current tasks forward 
link points to. 
The Scheduler also keeps track of an internal 

45 variable called $NEXT_ID. This variable is the 
Scheduler's best guess as to what the next task to 
execute afterthe task identified by $CURRENT JD 
completes its slice. 
The circular list data structure is referred to as 

so the Scheduler's queue. Placement within the 
queue with respect to the system task known as 
$LEVEL_TASK determines priority. This task is 
placed such that all the high priority tasks execute 
before it executes. Before passing control to the 

55 first low task, it changes the Scheduler's idea of 
which task is to execute after the next one so that 
the Scheduler's normal routines will execute one 
low priority task and then return to 
$SYSTEM_TASK, which is positioned just before 

60 the first high priority task. This is done by per- 
forming the following operations. 
$CURRENT_ID«- next low task 
$NEXTJD-$SYSTEM_TASK 
Then, all of the high priority tasks execute once 

65 and we return to $LEVEL_TASK, which now 
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allows the next low priority task to execute a slice 
before resuming execution at $SYSTEM_TASK. 
This causes all the high priority tasks to execute 
once for each execution of a slice of a low priority 
task. It insures that only one slice of execution by 
a low priority task will ever delay the response to 
executing any of the high priority tasks, no matter 
how many low priority tasks are queued. 

In operation, the Scheduler maintains a list of 
high priority tasks to be executed and a list of low 
priorities to be executed. Upon execution of an 
instruction pertaining to a particular task, approxi- 
mately every 500 microseconds, the Scheduler 
Manager 102 will then point to the next high 
priority task to be executed. Each task generally 
comprises more than one Instruction. In this 
manner, a number of tasks are being performed 
concurrently. Even though no two tasks are being 
operated on simultaneously, because of the rapid 
cycling through the tasks, rt appears there is 
simultaneous execution. 

For example, with reference to Figure 7 there is 
illustrated the high priority section and the low 
priority section of the Scheduler RAM on the CPM 
board. In operation, the Scheduler Manager 102 
will point to the execution of the next Instruction 
Module in Task 212, then Task 81, Task 150 and all 
the tasks in the high priority section ending with 
Task 6. Then the Scheduler Manager 102 will 
point to the next task in Sequence in the low 
priority section, e.g. Task 231. After execution of 
an instruction Module for Task 231, the control 
will return to the high priority section with Task 
212 to the last task, Task 6. The control will then 
jump to the low priority section, but this time to 
Task 12, the next task after the previously 
executed Task 231. 

Scheduling has been set up in this fashion for 
two very important reasons: 

1) No matter how many low priority tasks are 
active they cannot impact the response (time 
from wakeup or invocation to first slice being 
executed) or execution speed (number of slices 
executed per unit time) of high priority tasks. 

2) By only allowing each task to execute one 
slice at a time the response and execution speed 
under varying loads remains about the same. In 
addition, it gets the response faster than an 
execute to completion algorithm and the execu- 
tion speed faster and more consistent than an 
algorithm where new tasks are immediately 
executed. In most systems, the first few instruc- 
tions after a wakeup or invocation are the most 
critical or can be arranged to be so if necessary. 
This scheduling algorithm is tuned to give the 
best tradeoff between response and execution 
speed without adding prohibitive overhead. 

Additional states and operations have been 
added to the Scheduler to allow a type of interrupt 
processing. They are described in this section. 

Spooling: 

When processing an interrupt-type operation, it 
is often desirable to schedule a task for immediate 
execution. In our application, this occasion arises 


when processing interprocessor communica- 
tions. In order to react quickly and efficiently 
without substantially hindering the performance 
of the rest of the system, the spool-thread 

5 mechanism was used. This allows the user to put 
a task in a special form of suspension by thread- 
ing it A threaded task can be inserted into the 
short term scheduler quickly using the spool 
operation. A restriction is put on such a task; it 

10 will be given one execution slice and will then be 
considered to be dead until it is threaded and 
spooled again. This adds the states THREADED 
and SPOOLED to the set of possible states. 
When the Scheduler spools a task, that task will 

is be the next task to be executed after the current 
one finishes. This is accomplished by performing 
the following actions. 
<spooled_task>'s forward link*-$NEXT_ID 
$NEXTJD«-<spooled_task> 

20 Note that only the forward link of the spooled 
task is altered, and that no other member of the 
scheduler's queue has been altered to point to the 
spooled task. Thus, the spooled task executes 
only once and will never receive another slice?. 

25 

VIP Activation: 

When extremely fast interrupt-like operation is 
required, the VIP active mechanism Is used. This 
mechanism allows Very Important Processes to 

30 be CALLed by interrupt routines so that the 
interrupt routine can alias itself as a particular 
task and thus enjoy some of the capabilities 
formerly reserved only for tasks. These tasks 
execute until they become suspended or dead, 

35 and then return to the interrupt code that invoked 
them. In order to isolate this special mechanism 
from the rest of the system, ViP operations are 
kept separate from the rest of the system and are 
referred to as foreground scheduler operations. 

40 The Data Base Manager 106 controls all the 
data bases for the various tasks. One type of data 
base consists of two list structures for passing 
correspondence and control. The other data base 
is used to implement the EVENT function of the 

45 Operating System. 

The two list structures consist of a bytewide 
correspondence or byte stack and a wordwide 
control or word stack. Each list structure is a 
defined data area for maintaining a number of 

so substructures associated with an active task. Each 
list structure consists of cells which can be 
thought of as information packets. A cell consists 
of two or three page adjacent bytes of memory 
with each cell divided into two fields, a link field 

ss and a data field. The first byte in the cell is the link 
field and contains an index, that is, an address of 
a cell within the list structure. If the list structure is 
the correspondence or byte stack, the next byte is 
the data field. If the list structure is the control or 

so word stack, the next two bytes are dedicated to 
the data field. 

The structure that couples an active task to a 
substructure is a pointer list Two such lists are 
maintained by the Data Base Manager 106, one 

65 for each list structure. Each pointer list contains 
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an entry for each possible active task in the 
system. The entry consists of a pointer to a 
substructure within the list structure. The Run 
Time Identification of a task is used to vector into 
the pointer list to retrieve the pointer to a task 
substructure. Initially the pointer fist will be all 
zeros. 

The stacks are maintained via a header pointer 
and the stack pointer list pointing to the top of a 
stack associated with an active task. Within the 
stack, each cell has a link field and a data field. If 
the pointer to the stack is zero, there is no stack 
associated with this task. 

When an entry is to be added to the stack, a free 
cell is found, the index of the previously added 
cell is put in the link field of the new ceil, the data 
is moved to the data field and the index of the 
new ceil is put in the stack pointer associated with 
the current task. This has the effect of adding the 
new cell to the top of the stack. 

When an entry is to be removed from the stack, 
the data is removed from the cell on the top of the 
stack, the index and the link field of the cell is 
moved to the stack pointer (creating a new top of 
stack), and the ceil is added to the list of available 
ceils. 

The function of the Communication Manager 
110 is to provide for reliable and efficient control 
and manipulation of all communications between 
the microprocessors on the CPM, PHR, XER, MIR, 
DCR and RDHR boards 70, 72, 74, 76, 78 and 82, as 
shown in Figure 2. It is responsible for all format- 
ting preparation of information to be transmitted. 
It is also responsible for guaranteeing reliable and 
correct transmission of the information or notify- 
ing a higher level of control when this is not 
possible. It is the control link between the micro- 
processors. 

The Timer Manager 108 provides a set of 
Primitive operations for the ordered suspension 
and wake up of all tasks requiring real time or 
machine clock delays. The timer procedures use a 
two-celled singly linked list to maintain infor- 
mation on all suspended tasks. One ceil contains 
the tasks suspend duration while the adjoining 
ceil contains the link to the task with a greater 
than or equal suspended time duration. The last 
task on this list points to the list header. 

A task will normally request to be suspended 
for some duration and unless the SUSPEND is 
cancelled, its requested duration is run to comple- 
tion. 

A task could ask to be suspended for any of the 
following reasons: 

i) It's waiting for input, e.g. register finger, front 
panel command, pitch reset, paper path switches, 
or sensors in sorts. 

ii) A timed wait on either the Real Time Clock or 
the Machine Clock. 

Hi) It is in a RACE waiting on a case condition to 
be true, where the case conditions could be any of 
the reasons i or ii. 

In accordance with the present invention, there 
are four general cases or conditions for which a 
machine control can be suspended for the occurr- 


ence of a specific event. In particular, there is an 
input suspension case, (waiting for a transition of 
an input such as a switch), a time suspension case 
(waiting for the lapse of a certain period of 
5 machine or real time), a data suspension case 
(waiting for certain data to be presented or avail- 
able), and finally a process or task suspension 
case waiting for the completion of a specific task 
or process. 

10 With reference to Figure 5A, various RAM loca- 
tions on CPM board 70 are illustrated under the 
heading Event for maintaining the list of ail 
suspended tasks waiting for some event or 
occurrence. These events may be input transl- 

15 tions such as a switch transition, or for comple- 
tion of specified tasks with a specific Run Time 
Identification (RTID). In general, the RAM location 
includes the identification of the task waiting for 
the event and an identification of the event that 

20 the task is suspended on. In a preferred embodi- 
ment, there are only 64 entries at one time to the 
Event table. 

There are also timer tables or RAM location for 
various time delays that have been set up, as 

25 shown In Figures 6a and 5b, under the headings 
R.T.C. and M.C. and also data and argument 
tables for maintaining a list of data and argu- 
ments that are needed for further handling of 
tasks and processes under the general heading 

so DBM. In other words, there are lists maintained in 
RAM location of all the various tasks that are 
dependent upon a specific event, data time, or 
other task, and also identification of the specific 
event, data, time and task. These are known as 

36 suspended tasks that desire to be awakened or 
executed upon the occurrence of the desired 
event or at the desired state or condition of the 
control. 

Once the desired state is reached, such as an 

40 input transition, a completed tesk, a completed 
time interval, or the availability of certain data, the 
list of suspended tasks related to the specific 
occurrence are scanned to determine the specific 
tasks waiting on that specific occurrence. That is, 

45 the list of suspended tasks is scanned to deter- 
mine which ones should be awakened at that 
particular time. The control then vectors to the 
suspended task to continue execution at the point 
appropriate for the specific occurrence. 

so The Event table in RAM, for example, lists all 
the tasks waiting for an input Assume that there 
are five tasks listed in the event table waiting for a 
particular switch signal. As soon as the switch 
signal occurs, the control will scan the Event table 

55 looking for tasks waiting on this switch. The 
control will then make these five tasks active. 
Thus, only one table, the Event table has been 
scanned. In response, five tasks have been acti- 
vated without each task itself periodically scan- 

60 ning the switch to receive a wake up signal. 

"Racing" is implemented by allowing a task to 
suspend on multiple conditions or occurrences 
simultaneously. Execution of the task will con- 
tinue as soon as one of the conditions or 

65 occurrences is recognized. Continued execution 
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of the task depends upon which of the conditions 
was met. For example, a particular switch input 
might result in a certain type of execution, 
wherein a timer runout might result in another 
type of execution. When any one of the 
occurrences or conditions happens, all the other 
conditions for that task are removed from the 
various lists. By assigning a unique number to 
each condition, the control will check which 
number activated the task and automatically vec- 
tor to the appropriate code for execution. 

In the control code, RACING is provided by 
RACE/CASE statements. These statements are the 
means to test multiple conditions against time or 
against each other and to take appropriate action 
when any one of them becomes true. The follow- 
ing is an example of a RACE Instruction: 

RACE; 

CASE [ANYTIME] condition statement; 
[NEXTTIME] 

END; 

This use is an example of where the condition is 
limited to a simple comparison of two values. The 
statement following a CASE condition is executed 
if the condition is the first to be met. 

The difference between ANYTIME and NEXT- 
TIME is that ANYTIME triggers execution of the 
CASE statements if the condition is true when the 
RACE instruction is executed, while NEXTTIME 
specifically requests the next occurrence of the 
true condition. If neither is specified, ANYTIME is 
assumed. 

A RACE Instruction can have as many CASE 
statements as necessary, each followed by a zero 
or an executable statement. It is important to 
insure that at least one CASE condition will 
always occur in order to avoid deadlocks. One 
way to insure occurrence is to always include a 
timer CASE as part of the RACE. 
A sample RACE statement would be: 
RACE; 
CASE ELEVATOR=UP; 
statement; 
statement; 
CASE 13 SEC; 
statement; /*T1ME0UT»/ 
statement; 
END; 

This Instruction would cause the execution of 
the second set of statements under CASE 13 SEC 
if the condition ELEVATOR-UP takes more than 13 
seconds to become true. 

As an example of checking for paper at a 
switch, the following Instruction would be used: 

RACE 

CASE JAMTIME X MCLK 

DECLARE JAM 

CASE JAM SWITCH=PAPER 

statement 
END 

That is, if the jam switch fails to sense paper 
after X machine clocks, the statement "DECLARE 
JAM" is executed. Otherwise, the jam switch 
senses the paper in time, and the control will 
continue as directed by the statement 


While there has been illustrated and described 
what is at present considered to be a preferred 
embodiment of the present invention, it will be 
appreciated that numerous changes and modifi- 
5 cations are likely to occur to those skilled in the 
art, and it is intended In the appended claims to 
cover all those changes and modifications which 
fall within the true spirit and scope of the present 
invention. 

10 

Appendix A 
Instruction Modules 

The following are some of the more commonly 
used Instructions Modules in the high level 
is Instruction set: 

$CALL — Ca I IType, Task 

The task identified by Task is activated. Para- 
meters of the CALLer are transferred to the 
20 CALLee. The CALLee assumes the priority of the 
CALLer, and the CALLee becomes a member of 
the CALLer's family. The CALLer is restricted from 
executing further Directives until the CALLee 
completes its execution. 

25 

Process CALL Explanation: 

The unique (Task Control Buffer) TCB will be 
allocated for the CALLee. If the CALLee is cur- 
rently an active task, the CALL request is queued 
30 for execution when all pending instances are 
finished. 

Procedure CALL Explanation (a procedure is a 
task within a task) 
The CALLee will utilize the CALLer's resources, 
35 for example TCB, while it is executing. This 
implies that since the CALLee does not have a 
TCB of its own there is no mechanism to queue 
instances of that task. Since no TCB is required for 
the CALLee, there is no need for a (Static Task 
40 Control Block) STCB. 

$CANCEL— CompileTimelD 

Routine identified by CompileTimelD will cease 
execution. Each freshly cancelled task will begin 
45 executing its WILL All CHILDREN of the cancelled 
task will be cancelled in the SWILL statement It is 
only possible to cancel a direct CHILD of your own 
or a STARTed task in the local processor. 

50 CASE OF $DATA— Data Arguments, Branch Ad- 
dress 

There are four types of data: 

( 1 ) $B YTE A string of bytes, considered as is 

(2) $B!T A single bit derived by ANDing 
55 the given byte with the given 

mask. 

Data Arguments:: = Left Structure, Com- 
parator, RightStructure 

Compares LeftStructureto RightStructure using 
60 Comparator. Branch is made if comparison is 
true. Note: Regarding structures, comparison is 
true if comparison is true of EVERY set of corre- 
sponding bytes in the structures. 

6S 
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SEND — EndType 

If the current task is ready to complete, it is 
made inactive. If its Parent (if it has a Parent) is 
suspended on the current task* it is allowed to 
continue execution. 

Process END Explanation: 

If a Parent task exists, both tasks must be ready 
to synchronize before the current task is made 
inactive. If the Parent is not ready, the current task 


$RACE— Conditions 
Conditions: :=Condition/Condition Conditions 
Condition ::=CASE, Branch Address 
CASE::=$TIME, TimerType,Type,Time 
/ $TASK, CompileTimelD, ActiveStatus 
/ $DATA, DataArguments (see DATA write- 
up) 

/ $EVENT, Occurrence ($BIT, $DIRECT, 
Address, Mask), Sense 
TimerType: : =$REAL/$MACHINE 
EmptyStatus: : =$NOT_EMPTY 
ActiveStatus: : =$DIRECT/$I IMMEDIATE 


Occurrence: :+$ANY_TIME / $NEXT_TIME / 
null» 

Explanation: 
Ail Conditions are evaluated and as soon as one 
5 becomes TRUE, execution continues with the 
Directive determined by (i.e. located at) Bran- 
chAddress. 

$RESTORE_OS_CONTEX 
Explanation: 

This Directive retrives all necessary operating 
system context, previously stored by $SAVE_OS- 
_CONTEXT, in order to resume executing Direc- 
tives. 

$SAVE_OS_CONTEXT 
Explanation: 

This Directive will save all necessary operating 
context In order to allow non-Directive execution. 

$START— CompileTimelD 
Failure: Number of active tasks is at the maxi- 
mum. 

Explanation: 

The task (STARTee), identified by Com- 
pileTimelD, is activated. Priorities of STARTer are 
transferred to STARTee. The started task will 
initiate a new family. Both the STARTer and 
STARTee may continue executing Directives (as 
opposed to a $CALL). The STARTer's parameters 
are transferred to STARTee. Correspondence 
parameters are transferred from the STARTer to 
the STARTee. 

If the STARTee is a currently active task, the 
START request is queued for execution when the 
current activity completes. The tasks wiil execute 
in the order they were queued. 

$WAIT— Arguments 
Argument: :=$TIME, TimerType, Type, Time 
/ $TASK, CompileTimelD, ActiveStatus 
/ $DATA, DataArguments 
TimerType: :=$REAL / $MACHINE 
EmptyStatus: :=»$NOT_ EMPTY 
ActiveStatus: :=$ACTIVE / $NOT_ACTIVE 
Type::=$DIRECT / IMMEDIATE 
Explanation: 

The Condition is evaluated and no further Direc- 
tives are executed until the Condition is TRUE at 
which point the next Directive is executed. 

SWILL 
Explanation: 

Correspondence buffer is emptied. If current 
task has CHILDREN, ail CHILDREN are cancelled. 
The SWILL statement must be the first executable 
statement of the task's will. 


Appendix B 

Scheduler Manager Primitives 

Primitive: $P_MTS SSTART 

Inputs: $CURRENT_ID The task that is perform- 
ing the operation $FOUND_ID The tasks to start 

Outputs: None 


will suspend and wait for its Parent When both io 
are ready, correspondence is exchanged, the 
Parent is allowed to continue its execution, and 
the Child is made inactive. 

When a task is made inactive, the next pending 
request (if any) is made active and allowed to 15 
execute. 
Procedure END Explanation: 
The Parent task is allowed to continue execu- 
tion. 

20 

SFORK— CompileTimelD 
Explanation: 

The task (FORKee), identified by Com- 
pileTimelD is activated. CorrespondenceParame- 
ters of the FORKer are transferred to the FORKee, 25 
and the FORKee is made part of the family. The 
FORKer' s priorities are transferred to the FORKee. 
Both the FORKer and the FORKee continue 
executing (as opposed to the $CALL). 

If the FORKee is currently an active task, the 30 
FORK request is queued for execution when the 
current activity completes. The task will execute 
in the order they are queued. 

$JOIN— CompileTimelD 35 
Explanation: 

The current task is ready to synchronize with 
the task identified by CompileTimeiD. If that task 
is also ready to synchronize, correspondence is 
exchanged, that task is made inactive (see $END) 40 
and the current task will continue its execution. If 
that task is not ready to synchronize, the current 
task will suspend on that task becoming ready to 
synchronize. 

45 

SPRIORITY— Value 
Explanation: 

- Value is stored as the current task's priority and 
remains in effect until another $PRlORITY or until 
the task returns. Priority affects the given tasks so 
utilization of the processor, in relation to other 
tasks. 
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Explanation: The task identified by 
SFOUNDJD is moved from the DEAD state to the 
QUEUED state, assuming the priority of its Parent, 
which is identified by $CURRENT_ID. 

Primitive: $P_MTS $ENTER 

Inputs: $PRIORITY_ VALUE The priority value 
for the newly scheduled task 

$CURRENT_ID The task that is performing the 
operation 

SFOUNDJD The task that is to be entered. 
Outputs: None 

Explanation: The task identified by 
SFOUNDJD is moved from the DEAD state to the 
SUSPENDED state and given the priority value in 
$PRIORITY VALUE. 

Primitive: SP_MTS SDISCERN 

Inputs: $CURRENTJD 

Outputs: $PRlORiTY_VALUE 

Explanation: Returns the current task's priority 
in $PRIORITY_VALUE. This is useful for starting a 
Child task with the Parent's priority, since 
$PRlORJTY_VALUE can be used as an input 
variable for other Scheduler Primitives. 

Primitive: $P_MTS $RELEASE 

Inputs: SCURRENTJD The task to be removed 
from the Scheduler 

Outputs: SCURRENTJD 

Explanation: Moves the task identified by 
$CURRENTJD from the QUEUED state to the 
DEAD state. It then schedules the next QUEUED 
task for execution, since the current one no longer 
exists. 

Primitive: $P_MTS $FREE 
Inputs: SFOUNDJD 
Outputs: None 

Explanation: Moves the task identified by 
SFOUNDJD from the SUSPENDED state to the 
QUEUED state, not altering its priority. 

Primitive: $P_MTS SCAPTURE 

Inputs: SCURRENTJD The task to capture 

Outputs: $CURRENTJD 

Explanation: Moves the task identified by 
SCURRENTJD from the QUEUED state to the 
DEAD state. Since this leaves the current task 
DEAD, the next QUEUED task becomes the cur- 
rent task. 

Primitive: $P_MTS STHREAD 

Inputs: SCURRENTJD The task to thread 

Outputs: CURRENT JD 

Explanation: Moves the task identified by 
SCURRENTJD from the SPOOLED or QUEUED 
state to the THREADED state, preparing it for the 
next SPOOL. It then schedules the next QUEUED 
task for execution, since the task that was current 
is not "suspended" (THREADED). 

Primitive: $P_FGS $VIP_THREAD 

Inputs: SCURRENTJD The task to VIP thread 

Outputs: SCURRENTJD 


Explanation: Moves the task identified by 
SCURRENTJD from the SPOOLED or QUEUED 
states to the VIP THREADED state. 

5 Primitive: $P_MTS SSPOOL 
Inputs: SFOUNDJD 
Outputs: None 

Explanation: Causes the task identified by 
SFOUNDJD to be the task to be executed after 
to the current task has completed its slice. Note that 
if two SPOOLS are done in a row, they will cause 
LIFO execution of the SPOOLED tasks. 

Primitive: $P_FGS $V1P_ACTIVATE 
16 Inputs: SFOUNDJD The task to VIP activate 
Outputs: SCURRENTJD 
Explanation: Causes the value in SCURREN- 
TJD to be stored and the value in SFOUNDJD to 
be used in SCURRENTJD to determine the 
20 routine to "call". A call is made to the SSNEXT 
routine in the task control module, which vectors 
to the task's next activation address and allows it 
to execute NOW. When the task returns, using VIP 
suspend or VIP remove, execution continues at 
25 the 8085 Instruction just after the VIP activate 
Instruction, and SCURRENTJD is restored. 

Primitive: $P_FGS $VIP SUSPEND 

Inputs: SCURRENTJD 
30 Outputs: None 

Explanation: "Returns" to the routine that per- 
formed the VIP activate that gave this "task" a 
chance to execute. 

35 Primitive: $P_FGS $VIT_REMOVE 
Inputs: SCURRENTJD 
Outputs: None 

Explanation: "Returns" to the routine that per- 
formed the VIP activate that gave this "task" a 
40 chance to execute and moves the task identified 
by SCURRENTJD from the VIP THREAD state to 
the DEAD state. 

Primitive: $P_MTS SPRIORITY 
45 Inputs: $PRIORITY_ VALUE The new Priority 

SCURRENTJD The task to change 

priority 
Outputs: None 

Explanation: Modifies the Scheduler's priority 
so associated with the task identified by SCURREN- 
TJD to the value contained in SPRIORITY VALUE. 
Note: If the desired priority is the same as the 
current priority, this primitive performs a NO-OP. 

S5 Primitive: $P_MTS INITIALIZE 
Inputs: None 
Outputs: None 

Explanation: Sets up the Scheduler's internal 
data bases to include required system-related 

so tasks. The system requires three operating 
system tasks: $SYSTEM_TASK (priority =X '40'), 
SLEVELTASK (priority =X'20'), and BOTTOM task 
(priority=X'00'). Note that most of the above 
Primitives will not perform properly with less than 

& two tasks in the QUEUED state, so these three 
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tasks must not be altered with Scheduler 
Primitives once the system is running. 

Primitive: $P_MTS $RESET 

Inputs: $SYSTEMJD Identifier of 
$SYSTEM_TASK 

Outputs: $CURRENT_ID 

Explanation: Resets the Scheduler so that 
execution slices are allocated starting with the 
SYSTEM task and continue with the rest of the 10 
QUEUED task. 

Primitive: $P_STS SSCHEDULE 
Inputs: $CURRENTJD 

Outputs: $CURRENTJD M 
Explanation: Causes the Scheduler to indicate 
which task is to be given the next slice. 

Primitive: $P_STS $INSERT 

Inputs: $PRIORITY_ VALUE Priority of task to 20 
insert 

$FOUNDJD Task to insert 
Outputs: None 

Explanation: Moves the task identified by 
$FOUND JD from the DEAD state to the QUEUED & 
state, using the priority specified irr 
$PRIORITY_VALUE. 

Appendix C 

Task Manager Primitives 30 

$ALLOCATE,type 
type ::= $FOUND,$FORK 
| $FOUND,$START 
I $CURRENT,$EXTERNAL 

35 

Explanation: Allocates a TCB (dynamic internal 
storage) for the specified task. 

$ALLOCATE,$FOUND,$FORK 
Explanation: Allocates a TCB for the found task <° 
with parental linkage to the cur- 
rent task 
Inputs: FOUND_CTID 
CURRENTJD 
Outputs: FOUND JD *s 


$ALLOCATE,$FOU N D,$START 
Explanation: Allocates a TCB for the found task 
with parental linkage to the cur- 
rent task 
Inputs: FOUND_CTID 
CURRENTJD 
Outputs: FOUNDJD 

55 

$ALLOCATE,$CURRENT,$EXTERNAL 
Explanation: Allocates a TCB for the current 
task with external parental link- 
age 60 
Inputs: CURRENT_CTID 

PROCESSOR 
Outputs: CURRENTJD 

65 


$EXECUTE,function 
Function ::= $RELEASE,$CURRENT 
$RELEASE,$FOUND 
$VECTOR,$CURRENT 
$NEXT,$CURRENT 
$JOIN 

Explanation: Executes one of the prescribed 
functions on the specified TCB. 


$EXECUTE,$RELEASE,identifier 
Identifier ::= $CURRENT 
| $FOUND 

Explanation: Releases the identified (current or 
found) TCB's internal dynamic 
storage and makes the task inac- 
tive. 

Inputs: CURRENTJD 
FOUND JD 

Outputs: CCZS-another instance in the • 
queue 

FOUND JD=next queued task. 

$EXECUTE,$VECTOR,$CURRENT 
Explanation: Causes the current task to 
schedule a new activation 
address. 
Inputs: ACTIVATION^ ADDRESS 
CurrentJD 

$EXECUTE,$NEXT,$CURRENT 

Explanation: Causes the current task to con- 
tinue execution at its next 
scheduled address. 

Inputs: CURRENTJD. 

$EXECUTE,$JOIN 
Explanation: Attempts to join the current task 
to the found task. If join attempt 
fails the current task is set up to 
accept a JOIN from the found 
task. 

Inputs: CURRENTJD 

FOUND JD 
Outputs: CC,Z,S-successful. 

$FIND,case 
Case ::= $CHILDREN|$PARENT, 
$CHILDREN 

$FIND,$CHILDREN 
Explanation: Finds the instance of the proce- 
dure identified by FOUND_CTID 
that is a child of the procedure 
identify by CURRENTJD 
Inputs: CURRENTJD 
FOUND_CT1D 
Outputs: FOUND JD 
PROCESSOR 

CC,Z,S=ta3k inactive or child not 
found 

CC,C,S~child local 
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$FIND,$PARENT,$CHILDREN 
Explanation: Find the instances of the pro- 
cedures identified by CURRENT- 
_CTID and FOUND_CTID that 
are a parent-child pair 
Inputs: F0UND_CTT1D 
CURRENT_CTID 
Outputs: FOUND ID 
CURRENT JD 

CC,Z,C«Parent-child pair found 

WITIAUZE 

Explanation: Initializes the internal store of the 
TCM. 

$SiGNAL,$FOUND,$CANCELLED 
Explanation: Signals the found task to begin 

execution from its WILL 
Inputs: FOUNDJD 


$TEST,case 
Case ::= $CURRENT,|RUN|$COMPILE 
| $FOUND,$RUN|$COMPILE 

$CHILDREN,$RUN|$COMPILE 
I $PARENT,$RUN 
I $TCB_AVA!LABIUTY 

Explanation: Tests the specified TCB's (CUR- 
RENT, FOUND, CHILDREN, or 
PARENT) status using the 
specified identifier (RUN, COM- 
PILE, or EXTERNAL) as an index. 


$TEST,$CURRENT,$RUN 

Inputs: CURRENTJD 

Outputs: PROCESSOR 

CURRENT_CTID 
CC,Z,C=task active 
CC,C,C=task external 

$TEST,$CURRENT,$COMPILE 
inputs: CURRENT. CTID 
Outputs: PROCESSOR 
CURRENT_ID 
CC,Z,C=task active 
CC,C,C=task external 


$TEST,$FOUND,$RUN 

Inputs: FOUNDJD 

Outputs: PROCESSOR 
FOUND_CTID 
CC,Z,C=task local 
CC,C,C=task external 


STEST,$FOUND,$COMPILE 

Inputs: FOUND_CTID 

Outputs: PROCESSOR 
FOUNDJD 
COZ,C=task active 
CC,C,C=task external 


$TEST,$CH I LDREN ,$R UN 
Inputs: CURRENTJD 
Outputs: PROCESSOR 
5 FOUNDJD 

COZ,C=child active 
CC,C,C=child external 

$TEST^CHILDREN,$COMPILE 
w Inputs: CURRRENTJD 
FOUND_CTlD 
Outputs: PROCESSOR 
FOUND JD 

CC,Z,C=found task active & child of 
15 current 

CC,C,C=found task external 

$TEST,$PARENT,$RU N 
Inputs: CURRRENTJD 
2Q Outputs: PROCESSOR 
FOUNDJD 
FOUND_CTID 

CC,Z,C=current task has an active 
parent 

25 CC,C,C=parent is external 

$TEST,$TCB AVAILABILITY 
Inputs: none 

Outputs: CC,C,S=TCBs are available. 
30 aaims 

1. A system for controlling a machine including 
a plurality of operating components (72, 74, 76, 
78, 82) responding to control conditions, each 

35 operating component performing a plurality of 
tasks running asynchronously, with a number of 
the tasks being related to other tasks, the plurality 
of tasks producing a common result within a 
process, characterised by: 

*o a) a memory for storing a list of control values 
from the process which correspond to allowed 
starting conditions for related tasks; 

b) an input device for feeding back control 
values from the process, which values represent 

45 the status of the tasks in train, and each of which 
may be a starting condition for one of the other 
related tasks; 

c) a monitor for comparing the fed-back control 
values with the listed values, and for triggering 

so the respective component into starting on the 
respective task when one of the listed values is 
detected amongst the fed-back control values; 

d) means for generating an inhibition signal to 
the input device when the monitor detects the 

ss control value, with the effect that any different 
control value arriving later will be ignored, and 

e) means for resetting the monitor and remov- 
ing the inhibition signal when the respective task 
has been completed. 

60 2. The system of claim 1, wherein one of the 
control values becomes an input after the lapse of 
a specified period following generation of the 
inhibition signal. 
3. The system of claim 1 or 2, wherein one of 

55 the control values is a logic change. 
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4. The system of any preceding claim, wherein 
one of the control values is produced by comple- 
tion of a specified task. 

5. A method of controlling a machine having a 
plurality of operating components (72, 74, 76, 78, 
82) adapted to cooperate with each other to 
produce a result in response to receipt of a 
plurality of control inputs, the machine executing 
a plurality of tasks running asynchronously and of 
which at least one comprises a sequence of steps 
to be taken, the method characterised by the 
steps of: 

a) providing a list of control values from the 
process which correspond to allowed starting 
conditions for related tasks; 

b) feeding back control values from the process, 
which values represent the status of the tasks in 
train, and each of which may be a starting 
condition for one of the other related tasks; 

c) monitoring the fed-back control values to 
determine when one is the same as a listed value, 
and to trigger the respective component into 
starting on the respective task; 

d) inhibiting the input device when *a listed 
value is detected, to the effect that any different 
control value arriving later will be ignored, and 

e) resetting the monitor and removing the 
inhibition signal when the said respective task has 
been completed. 

6. The method'of claim 5, including the step of 
continually comparing the listed values with the 
fed-back values to determine the arrival of any 
one of the listed inputs. 

7. The method of claim 6, including the step of 
providing the appropriate response to the first 
input upon detecting the second occurrence of 
the first input 

8. A method as claimed in any of claims 5 to 7, 
for controlling the operation of the machine to 
start on one of two tasks depending on the arrival 
of one of two control inputs, the method compris- 
ing the steps of: 

listing one input; 

identifying the steps to be taken upon arrival of 
the one input; 

listing the other input to be monitored, 

identifying the steps to be taken upon arrival of 
the other input; 

comparing each of the fed-back control values 
with the listed inputs and, upon a successful 
comparison; 

determining the identity of the input which 
arrived first; 

executing only the task corresponding to the 
identified input, and 

ceasing monitoring the later arrival of control 
inputs. 

Patentanspiruche 

1. Ein System fur die Steuerung einer 
Maschine, mit einer Vielzahl von Operation skom- 
ponenten {72, 74, 76, 78, 82), die auf Steuerungs- 
bedingungen reagieren, wobei jede Operations- 
komponente eine Vielzahl von asynchron ablau- 


fenden Arbeitsgangen ausfuhrt, eine Anzahl von 
Arbeitsgangen in Beziehung zu anderen Arbeits- 
gangen gesetzt wird und die Vielzahl von Arbeits- 
gangen im Rahmen eines Prozesses ein gemein- 
5 sames Ergebnis hervorbringt, gekennzeichnet 
durch: 

a) einen Speicher fur die Speicherung einer 
Liste von Steuerungswerten von dem ProzeS, die 
erlaubten Startbedingungen fur die zugehorigen 

w Arbeitsgange entsprechen; 

b) ein Eingabegerat fur die Ruckfuhrung von 
Steuerungswerten von dem ProzeS, die den Sta- 
tus der Arbeitsgange im Gefolge reprasentieren 
und von denen jeder eine Startbedingung fur eine 

is der anderen zugehorigen Arbeitsgange sein 
kann; 

c) einen Monitor fur den Vergleich der ruckge- 
fuhrten Steuerungswerte mit den aufgelisteten 
Werten, und zur Triggerung der jeweiligen Kom- 

20 ponente fGr den Start des jeweiligen Arbeitsgan- 
ges, wenn einer der aufgelisteten Werte unter den 
ruckgefuhrten Steuerungswerten festgestellt 
wird; 

d) eine Einrichtung fur die Erzeugung eines 
25 Hemmsignals fur das Eingabegerit, wenn der 

Monitor den Steuerungswert feststellt, mit der 
Wirkung, daE jeder spater ankommende ander- 
sartige Steuerungswert ignoriert wird, und 

e) eine Einrichtung zum emeuten Einstelien des 
30 Monitors und zum Entfernen des Hemmsignals, 

wenn die jeweilige Aufgabe abgeschlossen 1st 

2. Oas System nach Anspruch 1, wobei einer 
der Steuerungswerte nach dem Ablauf einer spe- 
zhlzierten Periode, die der Erzeugung des Hemm- 

35 signals folgt, zu einem Eingabewert wird. 

3. Das System nach Anspruch 1 oder 2, wobei 
einer der Steuerungswerte eine Logikanderung 
ist. 

4. System nach wenigstens einem der vorange- 
40 gangenen Anspruche, wobei einer der Steue- 
rungswerte durch Vollendung eines spezifizierten 
Arbeitsgangs erzeugt wird. 

5. Ein Verfahren fur die Steuerung einer 
Maschine mft einer Vielzahl von Operationskom- 

45 ponenten (72, 74, 76, 78, 82), die zur Zusammen- 
arbeit miteinander vorgesehen sind, urn in Reak- 
tion auf den Empfang einer Vielzahl von Steuer- 
eingaben eine Ergebnis zu erzielen, wobei die 
Maschine eine Vieizahl von asynchron ablaufen- 

50 den Arbeitsgangen ausfuhrt, von denen wenig- 
stens einer eine Folge von durchzufuhrenden 
Schritten umfafct, charakterisiert durch die Ver- 
fahrensschritte: 

a) Bereitstellen einer Liste von Steuerungswer- 
55 ten von dem ProzeS, die erlaubten Startbedingun- 
gen fur zugehorige Aufgaben, entsprechen; 

b) RGckfuhren der Steuerungswerte von dem 
ProzeG, wobei die Werte den Status der Arbeits- 
gange im Gefolge reprasentieren, und von denen 

qq jeder eine Startbedingung fur eine der anderen 
zugehorigen Arbeitsgange sein kann; 

c) uberprufen der ruckgefuhrten Steuerungs- 
werte, urn festzustellen, wann ein Steuerungs- 
wert einem aufgelisteten Weert gielch ist. und die 

-5 entsprechende Komponente fur den Start des 
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jeweitigen Arbeitsganges zu triggern; 

d) Hemmen des Eingabegerates, wenn ein auf- 
gelisteter Wert festgestellt wird, mit der Wirkung, 
daS jeder andersartige Steuerungswert, der spa- 
ter ankommt, ignoriert wird; und 

e) emeutes Einstellen des Monitors und Entfer- 
nen des Hemmsignals, wenn die jeweilige Auf- 
gabe abgeschiossen ist 

6. Verfahren nach Anspruch 5, mit dem Verfah- 
rensschritt des kontinuierlichen Vergleichens der 
aufgelisteten Werte mit den ruckgefuhrten Wer- 
ten, urn die Ankunft von jeder der aufgelisteten 
Eingaben festzusteiien. 

7. Verfahren nach Anspruch 6, mit dem Verfah- 
rensschritt, auf den ersten Eingabewert bei Fest- 
stellung des zweiten Auftretens des ersten Einga- 
bewertes fur die angemessene Reaktion zu sor- 
gen. 

8. Verfahren nach wenigstens einem der 
Anspruche 5 bis 7, fur die Steuerung des Betriebs 
der Maschine r urn abhangig von der Ankunft von 
einer von zwei Steuereingaben, einen von zwei 
Arbeitsgangen zu starten, mit den Verfahrens* 
schritten; 

Aufiisten eines Eingabewertes; 

Identifizieren der durchzufQhrenden Schritte bei 
Ankunft des einen Eingabewertes; 

Aufiisten des anderen Eingabewertes der zu 
kontroliieren ist; 

Identifizieren der durchzufQhrenden Schritte bei 
Ankunft des anderen Eingabewertes; 

Vergleichen von jedem der ruckgefuhrten 
Steuerungswerte mit den aufgelisteten Eingabe- 
werten und, bei erfolgreichem Vergleich; 

Feststellen der Identitat des Eingabewertes, der 
zuerst angekommen ist; 

nur Ausfuhren des dem identifizierten Eingabe- 
wert entsprechenden Arbeitsgangs; und 

Einstellen des Kontrollierens von spateren 
Ankunften von Steuereingaben. 


Revendicatioous 

1. Systeme pour commander une machine 
comportant une multitude de composants opera- 
tionnels (72, 74, 76, 78, 82) repondant a des 
conditions de commande, chaque composant 
operationnel executant une multitude de taches 
s'effectuant de fagon asynchrone, avec un certain 
nombre de taches liees a d'autres taches, la 
multitude de taches produisant un resuitat com- 
mun dans un processus, caracterise par: 

a) une memoire pour stocker une liste de 
valeurs de commande du processus qui corres- 
pondent a des conditions de depart permises 
pour des taches concernees; 

b) un dispositif d'entree pour renvoyer des 
valeurs de commande du processus, valeurs qui 
represented I'etat des tiches en cours, et dont 
chacune peut etre une condition de depart pour 
Tune des autres taches concernees; 

c) un moniteur pour comparer les valeurs de 
commande renvoyeees aux valeurs Iist6es, et 
pour deciencher le composant respectif et le faire 


demarrer sur la tfiche respective lorsque Tune des 
valeurs listees est detectee parmi les valeurs de 
commande renvoyees; 

d) un moyen pour generer un signal d'inhibition 
5 pour le dispositif d'entree lorsque le moniteur 

detecte la valeur de commande, avec I'effet que 
toute valeur de commande differente arrivant 
ulterieurement sera ignoree; et 

e) un moyen pour remettre a I'origlne le moni- 
w teur et eliminer le signal d'inhibition lorsque la 

tache respective a ete achevee. 

2. Systeme selon la revendication 1, dans lequel 
rune des valeurs de commande devient une 
entree apres un laps de temps specific survant la 

is generation du signal d'inhibition. 

3. Systeme selon la revendication 1 ou 2, dans 
lequel Tune des valeurs de commande est un 
changement logique. 

4. Systeme selon Tune quelconque des revendi- 
20 cations precedentes, dans lequel I'une des 

valeurs de commande est produite par I'acheve- 
ment d'une tache specifies. 

5. Procede de commande d'une machine ayant 
un multitude de composants operationneis (72, 

26 74, 76, 78, 82) destines a cooperer les uns avec les 
autres pour produire un resuitat en reponse a la 
reception d'une multitude d'entrees de com- 
mande, la machine executant une multitude de 
taches se deroulant de maniere asynchrone et 

30 dont au moins I'une comprend une sequence 
d'etapes a suivre, le procede etant caracterise par 
les etapes conslstant a: 

a) fournir une liste de valeurs de commande du 
processus qui correspondent a des conditions de 

35 depart permises pour des tachese concernees; 

b) renvoyer des valeurs de commande du pro- 
cessus, valeurs qui representent I'etat des taches 

. en cours, et dont chacune peut etre une condition 
de depart pour I'une des autres taches concer- 
to nees;. 

c) surveilier les valeurs de commande ren- 
voyees pour determiner le moment ou I'une est la 
mime qu'une valeur Hstee, et pour deciencher le 
composant respectif pour le faire demarrer sur la 

4$ tache respective; 

d) inhiber le dispositif d'entree lorsqu'une 
valeur listee est detectee, a i'effet que toute valeur 
de commande differente arrivant ulterieurement 
sera ignoree; et 

so e) remettre a I'etat initial le moniteur et eliminer 
le signal d'inhibition lorsque la tache respective a 
ete achevee. 

6. Procede selon la revendication 5, compre- 
nant I'etape consistant a comparer continuelle- 

55 ment les valeurs listees aux valeurs renvoyees 
pour determiner I'arrivee de I'une quelconque des 
entrees listees. 

7. Procede selon la revendication 6, compre- 
nant I'etape consistant a fournir la reponse appro- 

60 priee a la premiere entree lors de la detection de 
la seconde apparition de la premiere entree. 

8. Procede selon I'une quelconque des revendi- 
cations 5 a 7, pour commander le fonctionnement 
de la machine afin de demarrer sur I'une de deux 
taches en fonction de I'arrivee de I'une de deux 
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comparer chacune des valeurs de commande 
renvoyees aux entrees listees et r lore d'une com- 
paraison reussie; 

determiner ridentite de I'entree qui est arrivee 
5 en premier; 

executer seulement la tache correspondant a 
I'entree identified; et 

cesser la surveillance de I'arrivee utterieure des 
entrees de commande. 

10 
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entrees de commande, le procede comprenant les 
eta pes consistant a: 
lister une entree; 

identifier ies eta pes a suivre lors de I'arrivee de 
ladtte entree; 

lister ('autre entree a surveiller; 

identifier les etapes a suivre lors de I'arrivee de 
i'autre entree; 
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